Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000061_owner-urn-ietf _Wed Nov 6 10:24:27 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12361 for urn-ietf-out; Wed, 6 Nov 1996 10:24:27 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12356 for <[e-mail]>; Wed, 6 Nov 1996 10:24:25 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA10219  (mail destined for [e-mail]); Wed, 6 Nov 96 10:24:20 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id KAA06852; Wed, 6 Nov 1996 10:18:33 -0500 (EST)
Message-Id: <[e-mail]>
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Martin J Duerst <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [URN] I18N does not belong in URNs
In-Reply-To: Your message of "Wed, 06 Nov 1996 11:04:14 +0100."
             <"josef.ifi..610:06.10.96.10.04.17"@ifi.unizh.ch>
Date: Wed, 06 Nov 1996 10:18:33 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> >That's an argument specifically against using UTF-8 at all.  I'd
> >like to hear more on this point from the UTF-8 proponents.
>
> The internet as such (TCP/IP) transports any kind of octets whatsoever.
> Some of the higher level protocols fail in this respect because
> of the short-sightedness of their designers. The worst is E-Mail,
> because it works not only on the internet, but also with other
> networks. But this is known, and with MIME, it is no problem
> anymore.

Disagree.  Many people do not have MIME mailers; many of those
who do have MIME mailers do not have the ability to send or
receive UTF-8 in MIME.  This isn't going to change anytime soon.
Even when it does change, people still won't be able to effectively
transcribe arbitrary UTF-8 characters.  This idea is a non-starter.

> Also, the URN syntax draft clearly specifies how URNs are
> transported over 7-bit channels (using %HH). This works for
> URLs, there is no reason it shouldn't work for URNs.

It doesn't work for URLs either if people see Kanji (or whatever)
on their screens (or business cards) but can't type it in.

> >| URNs should not be in any language, not even English.  I would
> >| enthusiastically support requiring all URNs to be in a restricted
> >| character set or otherwise discourage human friendliness (though due
> >| to grandfathering requirements, each URN scheme would need its own
> >| rules for ensuring this).
> >
> >That's an absolute show-stopper, if you are asking that existing
> >naming schemes develop encryption methods to transform their names
> >into unreadable strings.  People just won't do it because they
> >will see it as unreasonable and unnecessary.
>
> Exactly. And it is also an absolute show-stopper if the "restricted
> character set" still allows to use meaningful English, or if the
> restricted character set contains characters such as ~[]{}^<>\#|`
> ("unsafe" or not) that don't appear on the average non-US keyboard,
> or the "$" that can easily be seen as a demonstration of US "superiority".

My idea is that each URN scheme should specify its own rules for
how to make its part of the name space transcribable.  Using odd
characters such as those you mention would rule it out.  And each
URN scheme would also specify the discipline to be used for
assigning new names, such that they would not use meaningful
English or anything else.

As for the '$' and US superiority, get real.  I realize lots of
people are sensitive about such things, but hopefully we all know
that when viewed

> Keith, why don't you make an URN syntax proposal that only allows
> the characters "0" and "1"? It can easily be shown that with
> appropriate, protocol-or-whatever-specific encoding mechanisms,
> that will be enough to grandfather whatever has to be grandfathered.

I'm not going to dignify this with an answer.

> Or why don't you define a specific URN subspace, in which only
> numerical digits are allowed, and then see how well it gets populated
> in comparison with spaces that allow i18n?

You mean like ISBNs?   (oh sorry, they use digits '-' and 'X')

If you want long-term stable resource identifiers, you don't assign
them according to what's popular.

> >We should be building the big tent that everyone can live under,
> >not trying to close out name spaces we don't like.  If we were
> >to discourage readability we would find URNs ignored by
> >users of at least some name spaces, and we would no longer have
> >the unified noncolliding name space we presently contemplate.
>
> Exactly. URLs were supposedly designed to not be human-readable,
> or so I was told by some people that are now on this group.
> Current practice shows that this design aim was failed by
> a wide margin.

URLs inherently reflect the naming structure of their underlying
filesystems.  That design goal overrode any notions of readability
or non-readability for URLs.  But URNs should not be bound by such
constraints.

> Some people have learned something from this
> failure, namely that users want readability and meaning.

Absolutely they do.  But human-friendly identifiers are inherently
ambiguous -- if not when they are assigned, then they become ambiguous
over time.  This is inherent in the way we usually name things -- we
borrow meaning from elsewhere and lend it to something new.  Names are
nearly always imprecise.

> They even put it into telephone numbers, which, by the proponents
> of non-meaningful URLs/URNs, are cited as examples for well-
> working non-meaningful schemes.
>
> The conclusion is very clear: To deny readability and meaningfulness
> is to ignore human nature.

Except that URNs aren't really designed for human consumption.
(other than transcribability, which isn't really consumption)
The spaces to be grandfathered under URNs aren't designed for
human consumption either.  They do turn out to be useful -- they're
just not useful for what you have in mind.

> Anyway, incorporating UTF-8 into URNs is not an absolute
> showstopper at all. It is the first attempt at recognizing
> from the beginnig that i18n is an issue that is important,
> and designing a sound solution for it from the beginning.

Agreed that I18N is important.
But putting UTF-8 in URNs is technically unsound.

The sound solution is to put I18N (and all human friendly names)
in a layer above URNs.
That way, there is a clean separation between searching and
fuzzy matching of (inherently ambiguous) human-friendly
names, and resolution of computer-friendly resource identifiers.

> All other attempts at i18n on the internet were done as
> after-thoughts, a fact that lead to many clumsy and suboptimal
> solutions. Let's not make this mistake again.

Absolutely.  Let's therefore not put I18N in a layer where it doesn't
belong, and where it cannot work well, and concentrate on building
a layer where it will work well.

Keith